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(54) Provision of trusted services 

(57) A device for providing, for a limited period, a 
trusted service, such as trusted timestamping, without 
direct connection to a trusted service provider which 
guarantees the service provided by the device, has a 
tamper-proof enclosure containing a clock or other trust- 
ed service module, a protected memory containing a 
digital certificate and a private key, a battery for main- 
taining power to the clock and the protected memory, a 
processor and an interface for connection to a user's 
computer or workstation. Upon receipt of a request from 



the workstation via the interface, the processor obtains 
the current time from the clock and assembles it into a 
timestamp incorporating the digital certificate and 
signed using the private key. The timestamp is then sup- 
plied to the user via the interface. A radio receiver mod- 
ule may be included to enable adjustment of the clock 
in accordance with broadcast time signals. A usage lim- 
iter is provided to prevent the device from providing the 
trusted service outside the limited period of time (or lim- 
ited number of permitted usages). 
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Description 

Technical Field 

[0001 ] This invention relates to devices and methods 
for providing trusted services, for example timestamping 
of digital media such as word processor documents, dig- 
itised images and records of financial transactions. 

Background Art 

[0002] The advent of digital media and the wide- 
spread use of communications technology (such as the 
Internet) to disseminate such media has been accom- 
panied by the need to provide services which address 
the social and legal aspects of such media in a manner 
analogous to services available for tangible media. 
[0003] Thus there are many cases in which it is desir- 
able to be able to provide a verifiable time and date of 
existence of a document (i.e. a timestamp). Examples 
include receipts for payment of goods, contracts and 
other legal instruments, and documents recording the 
date of conception of ideas and designs. In the case of 
tangible documents several arrangements exist for 
timestamping: mechanically-printed receipts generally 
have the time and date of printing automatically incor- 
porated; a contract is usually dated at the same time 
that it is signed by the parties to it; and a provable date 
of existence of a document can be established by lodg- 
ing a copy with a trusted organisation, such as a bank, 
or by having it certified by a trusted official such as a 
notary. 

[0004] To facilitate reduced reliance on paper and oth- 
er physical records in commercial and other activities, 
corresponding arrangements must be provided for in- 
tangible media. Simply adding a digital record of time 
and date is insufficient, since digital media can in gen- 
eral be much more easily altered in an undetectable 
manner than is the case with physically-existing records 
- indeed this is one principal advantage of digital media. 
Accordingly digital timestamping services have been 
established. A trusted third party (the timestamp agent 
or trusted timestamp service provider - TTSP) appends 
a timestamp t, to a submitted digital document or data 
file, digitally signs the composite document (thereby 
vouching for the time of its existence), and returns the 
signed document including the timestamp t, to the sub- 
mitter. Subsequent verification of the digital signature 
(for example using private/public key techniques) then 
establishes, based on trust in the timestamp agent, the 
existence of the document at the time t, . 
[0005] Organisations have already been established 
to act as TTSPs. A user sends data to the TTSP, who 
sends it back timestamped and signed. In addition if the 
TTSP is presented with the signed timestamp and the 
original document it will verify that the document existed 
at the indicated time and has not been amended, if nec- 
essary in a legally recognised declaration. Techniques 



for such time stamping are described for example in US 
Patent 5 1 36 647, and software enabling users to apply 
timestamping themselves is available. 
[0006] There are, however, a number of pragmatic dif- 
s ficufties with this approach: 

there is potentially a lot of telecommunications traf- 
fic to the TTSP; 

the messages take time to travel, be signed and 
10 then returned, giving rise to performance problems; 
the link from the requestor to the TTSP has to be 
secured, for example, by using Secure Sockets 
Layer (SSL) software; 

the requestor needs to have access to the Internet; 
is - if the user is applying timestamping himself then it 
is likely that the clock is not "trusted" (i.e. there is 
no guarantee that the clock is accurate and is im- 
mune to tampering to change its setting). 

20 [0007] It is an object of this invention to facilitate the 
provision of trusted services, including trusted times- 
tamping. 

Disclosure of Invention 

25 

[0008] According to one aspect of this invention there 
is provided a device for providing a local trusted service 
to a user, having an enclosure and comprising within the 
enclosure: 

30 

a trusted service generator; 

a usage limiter; 

an identity generator; 

a private key store which is inaccessible from out- 
35 side said enclosure; and 

an interface for enabling communication between 
said user and said trusted service generator 

Brief Description of Drawings 

[0009] A device and method in accordance with this 
invention for providing a trusted service (in this case 
timestamping) will now be described, by way of exam- 
ple, with reference to the accompanying drawings, in 
which: 

Figure 1 shows an arrangement incorporating a de- 
vice for providing trusted timestamping; 
Figure 2 shows the device in more detail; 
Figure 3 shows the contents of a timestamp; 
Figure 4 shows part of the power supply circuitry of 

the device; and 
Figure 5 shows an interface for coupling the device 
to a workstation. 
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Best Mode for Carrying Out the Invention, & Industrial 
Applicability 

[0010] Referring to Figure 1 , a TTSP 10 loans a user 
who wishes to obtain timestamps a signing device 14. 
This dedicated device is enclosed in a sealed tamper- 
proof enclosure, and can be connected to the user's lo- 
cal network, or linked to their computer or workstation 
12 by a Universal Serial Bus (USB) or Small Computer 
Systems Interface (SCSI) connection. The signing de- 
vice 14 performs the required timestamping and signing 
locally to the user, i.e. without direct connection to the 
TTSP 10: the user sends it a message, and the device 
1 4 signs the message and returns it. The signing device 
14 contains a tamper proof clock, a certificate and the 
only copy of a private key; the certificate authenticates 
the identity of the TTSP 10, for example using known 
digital certificate systems based on public key encryp- 
tion techniques. 

[0011] The TTSP 1 0 provides two services: 

1. It manufactures the signing device 14, pre-pro- 
gramming it with a unique certificate and an asso- 
ciated private key; 

2. It provides the service of verifying that specific 
data were timestamped by a particular signing de- 
vice. 

[0012] Because the signing device 14 is merely 
loaned to the user, they have no right to open the enclo- 
sure, and must return the device on demand. At least 
two variants of the signing device 14 are envisaged. In 
the first variant, the device ceases to function after cer- 
tain conditions have been met (e.g. expiry of a prede- 
termined time period) and must be returned to the TTSP 
for disposal (i.e. from the user's viewpoint the signing 
device is disposable). In the second variant, the signing 
device 14 may be re-certified in situ. 
[0013] This arrangement has several advantages. 
For the user these include: 

faster timestamping (the delay incurred while mes- 
sages traverse the Internet is avoided, because the 
signing device 14 is local to the user); 
the user can be mobile, and does not have to be 
connected to the Internet; indeed the signing device 
14 can be embedded inside a portable device such 
as a laptop or handheld computer or a mobile tele- 
phone; 

more extensive use of timestamping is facilitated - 
any digital intellectual property can now be protect- 
ed; 

timestamping becomes essentially free or very low 
in cost. 

[001 4] The TTSP 1 0 benefits in the following ways: 
there is no need to provide large servers to perform 



the high volumes of timestamping in response to 
customer requests; 

a "consumable" business model for selling private 
keys becomes feasible. The signing device 14 can 
s be used in a number of ways, such as: 

1 Auditable log files transactions and other opera- 
tions (e.g. in a computer); the signing device 1 4 per- 
mits every log entry to be timestamped. 

10 2. Intellectual property protection; it is important to 
be able to prove that an idea was documented by a 
particular date, and that the documentation has not 
been subsequently modified; the timestamp can be 
used in relation to any digital content - video clips, 

15 compressed (e.g. JPEG) material, sound files, text 
files, etc. 

3. E-mail systems, to verify a message has not been 
altered and existed at a particular time. 

4. Merchant receipts (i.e. digital till rolls). 

20 5. Built-in to a digital camera so that a photograph 
is timestamped to indicate when it was generated, 
and possibly which camera took the photograph; 
this would make it possible to prove that the photo- 
graph predates all other copies of it, and has not 

25 been tampered with. 

6. As an extension to computer operating systems, 
to ensure that timestamps associated with the sys- 
tem and data used in it are generated by a trusted 
third party; this would prevent a user from rolling 

30 back the system clock to continue running software 
after expiry of a period of licensed use. 

7. In timestamped digital audio tape (DAT), CD- 
read/write (CD-RW) or writable digital versatile disc 
(DVD-RAM) storage devices; such devices would 

35 timestamp and digest each data block, or each file, 
with the timestamp being stored on the media. 

[0015] Figure 2 shows a practical implementation of 
the signing device 14. Referring to Figure 2, the device 

40 has a tamper proof enclosure 20, which is required to 
. prevent access to the components of the device (e.g. to 
extract the private key) or their alteration (e.g. to change 
the time in the clock). The enclosure can be made ef- 
fectively tamper proof by, for example, encasing the en- 

45 tire assembly in resin. Desirably the device 14 should 
detect attempts to tamper with it, either physically or by 
application of data signals, and respond by disabling it- 
self to prevent further use. Attempts at physical intrusion 
could be detected, for example, by means of a network 

50 of fine wires embedded in the resin and which would be 
broken if the resin is disturbed, or by means of micros- 
witches arranged to operate if the enclosure is opened. 
Attempts at intrusion via the interface can be detected 
by monitoring for excessive numbers of improperly for- 

55 matted input signals. 

[0016] As already noted the device 14 contains a 
clock 22 which may indicate date and time according to 
a specified standard, such as Co-ordinated Universal 
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Time (UTC), or time elapsed (e.g. in seconds) since a 
predetermined start instant. The design of the clock de- 
pends on the accuracy and resolution with which times- 
tamps are required over the intended working life of the 
signing device 14. For many purposes a drift of a few 
(c. 10) seconds a year is tolerable and this is readily 
achieved with modem quartz-oscillator clock circuits; in 
some cases a drift of no more than 0. 1 seconds per year 
may be required. Other techniques may be used as dis- 
cussed below. 

[0017] The private key and certificate are stored in a 
"protected" memory 24 which, together with the clock 
22, is supplied with power by a battery 26 even when 
the device 14 is unconnected. The memory 24 is pro- 
tected in the sense that its contents cannot be read di- 
rectly, either in response to input electrical signals or by 
physical examination. A CPU 28 (selected for high 
processing power and low power consumption) exe- 
cutes instructions in a program stored in the protected 
memory 24, using a second read-write memory 30 for 
intermediate results. The CPU 28 communicates with 
the user's computer or workstation 12 via an interface 
32 and a data link 34; an associated power line enables 
the device 14 to obtain power from the workstation 12 
so that the battery 26 is reserved for backup purposes 
(and can if desired be re-charged provided its voltage 
has not dropped too low - see below). 
[0018] A tamper detection module 38 within the de- 
vice 1 4 is coupled to the CPU 28 to indicate any attempt 
at tampering or intrusion; the CPU 28 responds to such 
an indication by disabling the device 1 4, either perma- 
nently or until its integrity has been checked by the TTSP 
10. If desired a radio module 40 for receiving broadcast 
time signals may be provided, to enable the clock to be 
corrected for drift as described below. 
[0019] The operation of the signing device 14, in out- 
line, is as follows. When the user wishes to add a times- 
tamp to a data file, the workstation 1 2 sends a message 
over the data link 34 to the device 14; this message may 
contain either the data file itself or digest created from 
the message using, for example, a hashing algorithm. 
In response the CPU 28 obtains the current time and 
date from the clock 22, and the private key and certifi- 
cate information from the protected memory 24. The 
CPU 28 uses these items of information to assemble a 
digital timestamp 42 as shown in Figure 3, and compris- 
ing: 

a record 44 of the date and time, and if desired a 
sequence number; 

a digest 46 of the data to be timestamped (obtained 
for example by hashing), enabling the timestamp to 
be uniquely related to the data without having to in- 
corporate the data themselves (possibly very large 
in quantity) in the timestamp; 
a copy 48 of the digital certificate for the signing de- 
vice 14 authenticating its identity, including the iden- 
tity of the organisation which issued that certificate 



and the public encryption key of the signing device; 
and 

a digest 50 of the items 44, 46 and 48, encrypted 
with the signing device's private encryption key, for 
use as a safeguard against fraudulent timestamps. 

The CPU 28 then returns the timestamp to the worksta- 
tion 1 2 over the data link 34. various aspects of the de- 
sign and operation of the device 1 4 are discussed below. 
[0020] A family of signing devices 1 4 varying in capa- 
bility is envisaged. For example, the signing device 14 
may be connected to the workstation 1 2 via: 

- a SCSI port; 
a serial port; 

a parallel port; 

- a USB port; 

- a PCI card; 

- a PCMI card; 

- a network, such as 10BaseT, 100BaseT, IP v4; 

or it may be built-in to the workstation 12. The network 
option would make it possible for the signing device 14 
to be used by multiple computers. However, this would 
require encrypted, authenticated, connections, perhaps 
using SSL. In addition, the network variant creates the 
possibility of having concurrent requests - necessitating 
either multiprocessing or queuing of the requests. Build- 
ing Personal Digital Assistants (PDAs) or other kinds of 
handheld computing devices with a built-in signing de- 
vice would permit mobile users to send timestamped/ 
signed e-mails, with greater integrity than faxes. 
[0021] The signing device can offer one or more of the 
following capabilities: 

signing, using a variety of algorithms; 
timestamping and signing; 
Message Authenticating Code (MAC) - i.e. a mes- 
sage digest with an associated key; 
inserting and removing messages from digital en- 
velopes. 

[0022] The user could be enabled to select which op- 
eration to perform, and to choose among different for- 
for the result of that operation. 
3] various arrangements are possible as regards 
ig use of the signing device 1 4 to a single worksta- 



the signing device does not know the identity of the 
workstation; 

the signing device collaborates with the host com- 
puter to confirm that it is the permitted user; 
the signing device has a smart card reader, or sim- 
ilar device, to enable it to confirm the identity of the 
user. 

[0024] Where the signing device is dedicated to a sin- 
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gle workstation, different tevels of security may be pro- 
vided: 

check the identity of the host computer 12 only on 
installation; 

permit the identity of the host computer to be set 
only on installation; 

permit the identity of the host computer to be 
changed at any time; 

check the identity of the host computer periodically 
- every hour, every minute, ... ; 
check the identity of the host computer for every re- 
quest. 

The identity of the host computer 1 2 may be established 
by the host computer's downloading a certificate accept- 
able to the signing device 14. Verifying the identity of 
the host would be performed by the signing device's 
sending a challenge to the host. The host would be ex- 
pected to encrypt the challenge with its private key cor- 
responding to the registered certificate. The signing de- 
vice would use the public key to decrypt and verify the 
response. Permitting the identity to be changed period- 
ically would permit the signing device 1 4 to be made us- 
er oriented rather than computer oriented. 
[0025] various options are possible for treatment of 
the signing device 14 at the end of its useful life: 

the device is returned to the TTSP after a pre-set 
period of time, or amount of usage; 
the device is capable of being certified for another 
period of use, without being returned to the TTSP. 
This would desirably entail the issue of a new serial 
identity code and private key. 

[0026] Occasionally it will be necessary to check that 
a timestamped document was indeed signed by a par- 
ticular device 14 at a given time and has not been 
amended. There are two alternatives for checking the 
integrity of the signed document: 

By the signed document owner 

[0027] The signed message contains a certificate of 
the signing device 14. The public key may be easily ex- 
tracted from this certificate. The message can now be 
checked to ensure that it is correctly signed. The certif- 
icate authority that issued the certificate can also be 
contacted to ensure that the certificate was valid at the 
time of signing. Thus the validity can be checked by an- 
yone with a copy of the signed message. 

By the trusted verifier 

[0028] The signed message can be sent back to the 
TTSP, or other trusted verifier, and they can check the 
message and return the timestamp, the identity of the 
signing device and a boolean value indicating whether 



the document is intact or, possibly, corrupted. In practice 
all of the checks performed by the TTSP can be per- 
formed by anyone with a copy of the signed document. 
Connection to the TTSP would be via asymmetric SSL 

s (as the requestor needs to know they are connected to 
a respected verifier). Once the signing device 14 has 
been withdrawn from service and returned, the TTSP 
may determine its clock drift etc. during its period of use 
and be able to make further guarantees as to interpo- 

10 lated clock drift at the time of timestamping. They can 
also confirm the physical integrity of the signing device. 
[0029] The purpose of the signing device 1 4 is to sign 
a certificate saying that it inspected the message at a 
particular time. It should not be possible to forge these 

is certificates. Thus it should not be possible to alter the 
clock 22 to a time of an attacker's choosing, various lev- 
els of guaranteed time accuracy are possible: 

a quartz clock with a drift of some predefined value 
n, seconds over 1 year; 

a thermally controlled quartz clock with a drift of 
(/^ < < n,) seconds over 1 year - implemented for 
example using a Peltier-effect oven; 
use of external radio time sources to update the 
clock 22 by means of radio signals received by the 
radio module 40; these time sources include 

cell phone eavesdropping (to detect time sig- 
nals embedded in the cell phone signals); 
Global Positioning System (GPS) signals; 
time reference signals broadcast from, for ex- 
ample, Rugby (England), Frankfurt (Germany) 
or Boulder (USA). 

[0030] It is important that options using external time 
references are carefully designed to counter the possi- 
bility of using the external time reference as the basis 
for an attack to create a fraudulent timestamp. This can 
be accomplished, for example, by letting the clock 22 
run independently and monitoring its drift relative to the 
external time reference. If the drift gets too large (say 
greater than 1 second per day) then something is as- 
sumed to be wrong - the clock 22 is failing or the device 
is being attacked - and disabling of the device is trig- 
gered. Similarly, if the external time reference is unavail- 
able for too long then the accuracy guarantees cannot 
be maintained and the device should disable itself. 
[0031] Each signing device 14 will have its own clock 
22 and these will not be synchronised. Therefore it is 
not possible to take timestamps from different signing 
devices and determine with any certainty which was is- 
sued first - the clocks will be different and will drift dif- 
ferently over time. 

[0032] It is also possible to monitor multiple time ref- 
erences. If the clock 22 is found to be running too fast, 
then it should be set back. However, it is important that 
timestamps have strictly increasing (monotonic) times. 
If the resetting were done naively it might result in a 
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timestamp being issued with an earlier time than a pre- 
viously-issued timestamp. In this case resetting of the 
clock should be deferred until it is safe to set the clock 
back (i.e. the adjusted time is later than the value of the 
last timestamp issued), or the clock should be slowed 
down until it matches the time reference. 
[0033] If the signing device 1 4 detects that it may have 
been compromised, it will disable itself. This may hap- 
pen, for example: 

if there is any attempt to tamper with the hardware; 
if there is any attempt to tamper digitally via the in- 
terface 32; 

after some predefined number, say 1,000,000, 

timestamps have been issued; 

after some predefined period of time, say 12 

months; 

after any significant drift between the internal clock 
and any external time reference (i.e. clock malfunc- 
tion or external attack); 

after disconnection from external time reference for 
too long; 

after being commanded to disable by TTSP; 
after being commanded to disable by the user; 
after the battery voltage drops below a pre-set 
threshold; 

after apparent clock malfunction - e.g. time has not 
incremented since the last clock reading. 

[0034] Upon disablement the TTSP will need to be in- 
formed and the device 14 returned to the TTSP. The 
TTSP would have to announce that the certificate has 
been retired. It is possible to resurrect a signing device 
by replacement of a memory module (such as a SIMM) 
containing a new certificate and private key, as de- 
scribed below, but this capability might itself pose a se- 
curity risk. 

[0035] Figure 4 shows how the signing device 1 4 can 
be disabled in the event that the battery voltage drops 
too low. The battery 26 is coupled to the rest of the cir- 
cuitry in the signing device through a switch 52 control- 
led by a voltage sensor 54 coupled to sense the battery 
voltage via the switch. While the battery voltage is above 
the pre-set threshold, it suffices to cause the vortage 
sensor 54 to keep the switch 52 closed. However, if the 
voltage once drops be tow the threshold, the switch 52 
is caused to open, thereby removing power from the 
signing device circuits including the voltage sensor 54 
itself. Thereafter, even if the battery is replaced or re- 
charged, the open switch 52 blocks the supply of power 
to the voltage sensor 54, so the signing device is disa- 
bled. The voltage sensor 54 may conveniently have a 
disable input 56 which can be activated by the tamper 
detect ton module 38 to open the switch 52 in the event 
that tampering with the signing device 14 is detected. 
[0036] It is undesirable for a signing device 14 to be 
used for too long - its private key stands more chance 
of being compromised the longer it is used. Accordingly, 



a usage limiter is provided to cause the device 1 4 to dis- 
able itself, as noted above, after a pre-set time (e.g. 12 
months) or after it had issued a pre-set number (e.g. 
1 ,000,000) of timestamps. These parameters are stored 

5 in the protected memory 24. The device's certificate 
would then be retired. The user would have to pay for a 
new device with a new certificate and private key - this 
would probably be acceptable if the device is reasonably 
cheap. Other advantages of having the device 1 4 in use 

10 for a fixed period of time only are that the capacity of the 
battery 26 can be chosen to ensure it is sufficient to op- 
erate the clock 22 for the designed period of use, and 
that the clock's drift should stay within closely definable 
limits. 

is [0037] At the end of the device's lifetime there are two 
strategies that may be adopted: 

- physically return the device to the TTSP for disposal 
or recycling of the hardware; or 
20 - replace the key components (the private key and 
the certificate) to re-certify the device in-situ via the 
use of a SI MM. This would only be appropriate if the 
clock 22 can be checked for drift. 

25 [0038] It is possible to provide a secure communica- 
tions link to the TTSP in a number of ways, such as that 
described for example in European patent application 0 
756 397. In this scenario, the signing device 14 would 
contain a large quantity (e. g. 20 megabytes) of one-time 

30 pad encryption key agreed with the TTSP. All commu- 
nications between the signing device and the TTSP 
would be exclusive OR'ed with sections of the one-time 
pad key, each section being used once only- When all 
of the one-time pad key has been used, the signing de- 

35 vice would have to be physically returned to the TTSP 
[0039] Smartcards (credit cards containing process- 
ing and memory devices) can provide some of the func- 
tionality required for the signing device 1 4. They are typ- 
ically very secure, and so could safely contain the pri- 

40 vate key. They can also in principle support cryptograph- 
ic operations. However, they have a number of deficien- 
cies which would preferably be rectified for practical use: 

they have no internal power source; 
45 - they have no clock; 

they have limited memory capacity; 
the eight input/output (I/O) lines are not very robust 
- although are probably good enough if they are not 
being continually inserted and removed; 
50 - they have a slow I/O transfer speed e.g. as low as 
9600 baud. 

Nonetheless smartcards could provide a way of person- 
alising a signing device, in the same way that a SIMM 
55 module is used to personalise a GSM mobile phone. 
Thus a smartcard could be placed inside the signing de- 
vice 14 and then the enclosure sealed. 
[0040] Figure 5 shows one possible implementation 
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of the interface module 32 for communication with the 
workstation 12. Referring to Figure 5, an application pro- 
gram 60 sends a timestamp request to interface soft- 
ware 62 associated with the signing device 14. This in- 
terface software 62 provides a set of standard applica- s 
tion programming interface (API) functions, e.g. to re- 
quest signing of a message. Actual communications be- 
tween the workstation 1 2 and the signing device 1 4 are 
handled solely by the interface software 62. Only when 
the signing device 14 is satisfied predetermined criteria 
have been met, e.g. following an exchange of challenge- 
response messages with the interface software 62, 
does a timestamped message get passed back to the 
software 62 for forwarding to the application program 
60. In this way the signing device include various au- 
thentication protocols in the process of issuing a times- 
tamped message. 

[0041] The signing device 14 might require the host 
workstation 12 to refer back, periodically, to the TTSP 
for instructions. Only if the correct responses are for- 
warded by the host from the TTSP would the signing 
device continue working. 

[0042] Various implementations of the signing device 
14 are possible. The simplest signing device produces 
a timestamped signature of a message sent by the user. 
Typically this message is a digest of a document, pro- 
viding two advantages over sending the document itself 
to the signing device: 

the delay incurred in sending the (potentially) large 
document to the signing device is avoided; 
the signing device cannot see the contents of the 
document. 

[0043] The protocol is as follows: 

1 . the user submitter sends {message} to the sign- 
ing device 14; 

2. the signing device sends signaturefsigning de- 
vice's certificate, {message, timestamp}) back to 
the user. 

[0044] The signing device is basically indicating that 
it 'saw' the message at a particular time. It does not say 
anything about who supplied the message. 

Variant #1 

[0045] The first variant of the basic timestamping 
signing device produces a timestamped signature of a 
document. The signing device produces a digest of the 
document, which is then timestamped and signed. 
[0046] The protocol is: 

1 . the user sends {doc} to the signing device 14; 

2. the signing device sends signaturefsigning de- 
vice's certificate, {digestfdoc), timestamp}) to the 
user. 



The timestamped signature now contains details of who 
signed the document (in the certificate 48), the digest of 
the document and the time (as seen by the signing de- 
vice) when the document was signed. 
[0047] This permits the TTSP to vouch that the origi- 
nal document was seen, and not just a digest of the mes- 
sage, at a particular time. The enclosed digest of {doc} 
permits the TTSP, and any other interested party, to 
check the digest against the document to ensure it has 
not been modified. Again, this variant provides no infor- 
mation about the identity of the submitter. 

variant #2 

[0048] This variant combines the basic signing device 
with variant #1 . The user provides two pieces of infor- 
mation - a document and a message. The message and 
a digest of the document are embedded in the times- 
tamped signature. 
[0049] The protocol is: 

1 . the user sends {doc, message] to the signing de- 
vice 14; 

2. the signing device sends signature (signing de- 
vice's certificate, {message, digestfdoc), times- 
tamp}) to the user. 

Typically, the user might use the message field to supply 
a certificate. Obviously, the signing device does nothing 
with the message field other than to embed it, and pro- 
tect it, in the result. 

variant #3 

[0050] It is possible to use variant #2 to store a certif- 
icate of the submitter in the timestamp. However this 
does not mean that the TTSP is verifying the owner of 
the certificate as being the user. Certificates are public 
knowledge and can be copied or forged. 
[0051] So another variant of the signing device might 
also verify the identity of the submitter. To this end: 

1 . the user sends {doc, submitter certificate} to the 
signing device 14; 

2. the signing device sends {Efpublic key from sub- 
mitter certificate, random message)} to the user; 

3. the user sends {random message] to the signing 
device; 

the submitter must use their private key to ex- 
tract the random message, thus proving they own 
the certificate; the signing device 1 4 checks the ran- 
dom message is returned correctly to ensure the 
certificate is valid; 

4. the signing device sends signaturefsigning de- 
vice's certificate, {digest(doc), timestamp, submit- 
ters certificate}) back to the user 

The timestamped signature now contains details of who 
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signed the document, the digest of the document, the 
time (as seen by the signing device) when the document 
was signed and details of who submitted the document. 
[0052] A LAN-connected version of the signing device 
14 would probably use SSL to ensure encrypted, au- 
thenticated links. The submitter's certificate would be 
known to the signing device and so verification would 
not be required. 

[0053] It is unlikely that the signing device would go 
back to the certificate issuing authority to check the sup- 
plied certificate is still valid. That would be up to the user 
of the timestamp information to verify. The signing de- 
vice is simply accepting the certificate as data, checking 
it was owned by the submitter and then embedding it 
inside the timestamp. 

[0054] Although the invention has been described in 
the context of providing trusted timestamps, it can be 
applied equally to the provision of any other kind of trust- 
ed service, such as the signing of messages without 
timestamping, or the provision of secure random num- 
bers for use as seeds or keys in encryption. 



lidity of timestamps provided by the trusted clock. 

6. The device of any one of the preceding claims, in- 
cluding a power source and wherein the device dis- 

5 ables itself from providing the trusted service if a 
functional parameter of the power source ceases to 
satisfy a predetermined criterion. 

7. The device of claim 6, wherein the predetermined 
10 criterion requires that the power source voltage al- 
ways exceeds a predetermined threshold value. 

8. The device of claim 6 or claim 7, wherein an elec- 
trically-operated switch which controls supply of 

is power to circuitry in the device, including the switch 
itself, is held closed by the power source while the 
predetermined criterion is satisfied, and opens to 
disable the circuitry, including the switch, if the cri- 
terion ceases to be satisfied. 



Claims 

25 

1 . A device for providing a local trusted service to a 
user, having an enclosure and comprising within the 
enclosure: 

a trusted service generator; 30 

a usage limiter; 

an identity generator; 

a private key store which is inaccessible from 
outside said enclosure; and 
an interface for enabling communication be- 35 
tween said user and said trusted service gen- 
erator. 

2. The device of claim 1, wherein the enclosure is 
tamper-proof. 40 

3. The device of claim 1 or claim 2, wherein the usage 
limiter comprises a trusted counter adapted to be 
incremented or decremented every time the trusted 
service is invoked until a predetermined number is 45 
reached, whereupon the device ceases to be able 

to provide the trusted service. 

4. The device of claim 1 or claim 2, wherein the usage 
limiter comprises a trusted clock, and wherein the so 
device is adapted such that when a predetermined 
time is reached on the trusted clock, the device 
ceases to be able to provide the trusted service. 

5. The device of any one of the preceding claims, 55 
wherein the trusted service generator is a trusted 
clock having an associated power source and the 
identity generator identifies a guarantor of the va- 
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